home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-171 < prev    next >
Encoding:
Text File  |  1988-12-01  |  10.8 KB  |  221 lines
  1.  
  2.  
  3.  
  4. IEN 171
  5.  
  6.                                                              Danny Cohen
  7.                                                                USC / ISI
  8.                                                          18 January 1981
  9.  
  10.  
  11.                 Addressing in the ARPAnet, another visit
  12.                 ----------------------------------------
  13.  
  14.  
  15. As  you  all  remember  the addressing in the HOST/IMP interface for the
  16. ARPAnet has the following format (as defined in 1822):
  17.  
  18.             8               8                      16
  19.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  20.     |///IP-net-ID///|    H O S T    |           I   M   P           |
  21.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  22.      9            16 41           48 49                           64
  23.  
  24. Please allow me to take the liberty of showing it in  a  more  "logical"
  25. and consistent order:
  26.  
  27.             8                      16                       8
  28.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  29.     |///IP-net-ID///|           I   M   P           |    H O S T    |
  30.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  31.  
  32. In the rest of this discussion we will use only this "logical" order.
  33.  
  34. It  is  well  known that for the time being the Net-ID field is not used
  35. and that  IMP  numbers  may  be  contained  in  a  single  8-bit  field.
  36. Therefore, ARPAnet addresses are of the form:
  37.  
  38.             8               8               8               8
  39.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  40.     |///IP-net-ID///|     I M P     |       0       |    H O S T    |
  41.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  42.                                    2
  43.  
  44. I  believe that a single 8-bit field for the IMP address may be found in
  45. a (relatively) near future to be too restrictive.  Let's assign a 12-bit
  46. field for this purpose (even though  I  believe  that  10  are  enough).
  47. Using 12 bits for IMP-addressing the following format is suggested:
  48.  
  49.             8                  12                      12
  50.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  51.     |///IP-net-ID///|         I M P         |        H O S T        |
  52.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  53.  
  54. Hence,  I propose an arrangement which will allows a connection of up to
  55. 4,096 hosts to a single IMP (out of 4,096), or more hosts  out  of  less
  56. IMPs if the IMP-address field is chosen to be smaller than 12 bits.
  57.  
  58. One  of  the best ways to connect many hosts to an IMP at any site is by
  59. contracting BBN to provide that many IMP/HOST interfaces.   Another  way
  60. is  by  sharing a few IMP ports by several hosts, by using multiplexers,
  61. port-expanders or other multi-access schemes. One  candidate  technology
  62. for  such  multiplexing  is  the  one  commonly  referred  to  as "local
  63. networks".
  64.  
  65. I advocate that the details of this arrangement are of interest only  of
  66. that  site,  and  are  no  one  else's  business.  In other words, these
  67. details do not have to be made available outside of that site.
  68.  
  69. The word HOST in all of the above diagrams is most misleading.  The  IMP
  70. has  absolutely  no notion of host.  All it knows is which port is used.
  71. This field is used to identify the IMP port, not the HOST.
  72.  
  73. It is proposed here that if there are several  hosts  sharing  the  same
  74. port, then a HOST-ID field should follow the PORT-ID field.
  75.  
  76. How  big  should these two fields (the PORT-ID and the HOST-ID) be?  The
  77. answer depends on the local configuration at each  site.  One  site  may
  78. chose to connect its 64 hosts by using 64 ports bought from BBN, another
  79. by using a smaller number of ports each supporting several hosts through
  80. some  port  expanders,  and  another site may connect all of its 64 host
  81. through a single port.
  82.  
  83. Obviously, hosts which share the  same  ports  have  to  understand  the
  84. advantages  and  disadvantages  which  are associated with this sharing,
  85. such as the flow-control which is based  on  port-pair,  port  blocking,
  86. etc.   It is not unreasonable to expect the personnel at each site to be
  87. intelligent  enough  to  understand  these  issues  and  to   make   the
  88. appropriate decision about it, as best suits the particular situation.
  89.  
  90. The  notion  which  is  advocated  here  is that the distinction between
  91. PORT-ID and HOST-ID does not have to be  known  and  understood  to  the
  92. outside,  just  as on the ARPAnet the distinction between the IMP-ID and
  93. the HOST-ID does not  have  to  be  understood  even  at  the  HOST/HOST
  94. protocol level.
  95.                                    3
  96.  
  97. Again,  where does the proposed PORT-ID field end and the HOST-ID start?
  98. One possible approach is to legislate the  same  answer  for  all  IMPs,
  99. regardless  of  the  particular  situation  of  each one.  This has some
  100. trivial simplification benefits.
  101.  
  102. Another is to follow the IP philosophy of NOT legislating the format  of
  103. each  intranet  addressing, and leaving it as the "REST" which has to be
  104. understood only at the local environment for which it is designed.
  105.  
  106. Following this philosophy it is  proposed  that  the  PORT-ID  field  be
  107. defined  to  be  of a variable length, defined specifically for each IMP
  108. according to the local requirements which it has to support.   Let  N(i)
  109. be the length PORT-ID field at IMP(i), i.e., the IMP whose ID is i.
  110.  
  111. Hence,  once  a message arrives at IMP(i) for any of its hosts, this IMP
  112. should look at the top  N(i)  bits  of  the  PORT-ID/HOST-ID  field  and
  113. extract the PORT-ID for the port to be used for forwarding this message.
  114. Neither the extra processing nor the storage requirements for supporting
  115. this scheme seem to be excessive.
  116.  
  117. Obviously  there  must  be some processor on the other end of every port
  118. which is capable of handling the required handshake with the IMP.
  119.  
  120. The flow control which is now based on port/port pairs must  be  somehow
  121. modified  since  the  notion  of  remote  port does not exist under this
  122. proposal.  Without getting  into  details  here  we  suggest  that  this
  123. problem  can  be  solved,  and  the  difficulties  associated  with this
  124. modification are outweighed by the benefits of this scheme.
  125.  
  126. The main advantage of such a scheme, in comparison with having some kind
  127. of a gateway (or equivalent, such as SRI's port-expander)  is  that  the
  128. forwarding  may  take  place in a very efficient way without the need to
  129. "open each envelop", understand the  protocol  used,  finding  the  full
  130. IP-address  (whose  position may vary even for different versions of IP)
  131. and decipher from it where to forward the message. The  author  of  this
  132. short  note  dares  suggest  that  efficiency  is  not  a  sign of moral
  133. turpitude and that we should be as efficiency oriented as possible.
  134.  
  135. Hence, our proposed format for the ARPAnet addressing is:
  136.  
  137.             8                  12                N(i)   /  12-N(i)
  138.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  139.     |///IP-net-ID///|         I M P         |   P O R T / H O S T   |
  140.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  141.  
  142. This format is "logical" and suggestive only. It is well understood that
  143. these bits  may  be  packed  in  a  different  order  and  over  several
  144. non-consecutive fields (e.g., 9-16 and 41-64).
  145.                                    4
  146.  
  147.                  A problem with the current 1822 format
  148.                  --------------------------------------
  149.  
  150. The   basic   notion  of  1822  is  that  it  is  a  IMP/HOST  protocol.
  151. Unfortunately, 1822 is the IMP/PORT (or  IMP/INTERFACE)  protocol.    If
  152. every PORT always supports only one host then 1822 is really an IMP/HOST
  153. protocol.    However,  with today's technology where hosts range in size
  154. (and cost) over several orders of magnitude it is  not  unreasonable  to
  155. expect that several hosts share a single IMP-PORT.
  156.  
  157. This  may  be  accomplished  in  a  variety  of ways which we better not
  158. discuss here since this is too rich topic for this discussion.
  159.  
  160. Most  modern protocols carry both the TO: and the FROM: addresses across
  161. the "subscriber" interface.  It would be nice, and most helpful, if 1822
  162. would carry both the destination and the source addresses, just like IP,
  163. TCP, PUP and Ethernet - to name a few.
  164.  
  165.  
  166.             Background (or why we, at ISI, like this scheme)
  167.             ------------------------------------------------
  168.  
  169. I apologize for introducing the motivation  at  the  end  of  the  note,
  170. rather than at its beginning.
  171.  
  172. At  ISI  any  scheme  which  would  allow  a  fast  and efficient packet
  173. multiplexing between many hosts and networks is  a  cornerstone  of  the
  174. architecture of our new environment.
  175.  
  176. We,  at  ISI,  would  like  to be able to multiplex packets with minimal
  177. processing and without the need to "open  each  envelop"  and  read  the
  178. "inside letter" and to understand the higher level protocols in order to
  179. figure  where  to  forward  the  messages.    At  the  level where these
  180. multiplexing techniques reside even IP is a higher level  protocol,  and
  181. so are ST and PUP.
  182.  
  183. We  plan  that  the  entire  ISI  environment would share a single 8-bit
  184. address space, spanned by several local networks, Funnels  and  probably
  185. some other packet-multiplexing schemes.
  186.  
  187. This  environment,  which  we  like  to refer to as a "site", would have
  188. connections to several IP-Networks (capital N!). The preferred  mode  of
  189. operation  is  to use some direct packet multiplexing schemes to deliver
  190. the packets directly to their destinations, each of which is capable  to
  191. perform  all  the  IP-processing. The exception would be to route packet
  192. through an explicit Gateway, and even this may be used only for part  of
  193. the  traffic,  like for outgoing packets which require routing decisions
  194. but not for incoming ones.
  195.                                    5
  196.  
  197. According to our philosophy  the  choice  for  our  site  between  using
  198. centralized  site  gateway  and a "distributed-gateway" is our business,
  199. and no one else's. A distributed gateway is a  scheme  where  each  host
  200. performs  all  the  necessary  IP-level  functions.   Note that even the
  201. existence of a centralized gateway does not alleviate the need  for  the
  202. distributed  one, because every terminal-host must be able to understand
  203. IP, unless it has a surrogate which performs this task for it.
  204.  
  205. We happen to believe that other sites with a large number of hosts would
  206. like to implement similar  schemes  which  support  high  efficiency  of
  207. packet forwarding mechanisms.
  208.  
  209.  
  210.                           A concluding comment
  211.                           --------------------
  212.  
  213. The  notion  which  is advocated in this note is by no mean new. We have
  214. learned long ago that  any  level  of  protocol  should  always  contain
  215. multiplexing  information for the next level. In the few instances where
  216. this is not done - a price is paid for this error.
  217.  
  218. For example, the good old LINKs (or Message-ID's) used to  play  such  a
  219. role, and so do NCP-SOCKETs and TCP-PORTs.
  220. -------